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An Application of the BGP Community Attribute 
in Multi-home Routing 


Status of This Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


This document presents an application of the BGP community attribute 
[2] in simplifying the implementation and configuration of routing 
policies in the multi-provider Internet. It shows how the community 
based configuration can be used to replace the AS-based customization 
of the BGP "LOCAL PREF" attribute, a common method used today. Not 
only does the technique presented simplifies configuration and 
management at the provider level, it also represents a paradigm shift 
in that it gives the potential for the customer to control its own 
routing policy with respect to its service provider, as well as 
providing the ability for policy configuration to be done at a prefix 
based granularity rather than the more common AS based granularity. 


1. Introduction 


In the multi-provider Internet, it is common for a service subscriber 
(i.e., customer) to have more than one service provider, or to have 
arrangements for redundant connectivity to the global connected 
Internet. As discussed in [3], routing strategies in these cases 
usually require coordination between the service subscriber and its 
providers, which typically leads to customization of router 
configurations (e.g., BGP "LOCAL_PREF") not only by the subscriber, 
but also by its providers. Due to the large number of customers a 
provider serves, customization of router configurations at the 
provider level may present management and scalability problems. 


This document presents an application of the BGP community attribute 
in simplifying the implementation of routing strategies in the 
multi-provider Internet. More specifically, the technique presented 
uses a community-based, rather than the common AS-based, 
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configuration of the BGP "LOCAL_PREF". It essentially removes the 
need for customized configuration of the BGP "LOCAL _PREF" attribute 
at the provider level while maintaining the same level of routing 
functionality and flexibility. 


It also represents a paradigm shift in that it gives the potential 
for the customer to control its own routing policy with respect to 
its service provider, as well as providing the ability for policy 
configuration to be done at a prefix based granularity rather than 
the more common AS based granularity in use today. 


2. AS-based Configuration and its Drawbacks 


As discussed in [3], in today’s multi-provider Internet, customized 

configuration of the BGP "LOCAL_PREF" attribute is often required to 
implement common routing strategies such as load-sharing or backup. 

There are two main reasons: 


o Lack of available implementations and deployment of routing 
software that supports the "Destination Preference Attribute" 
(DPA) as specified in [4]. 


DPA allows one to specify a globally transitive preference so 
that return traffic favors certain path. As discussed in [3], 
the attribute will be very useful in influencing route selection 
for routes with identical "LOCAL_PREF" and equal AS-path length. 


o In the multi-provider Internet, it is common for a provider 
to assign higher BGP "LOCAL PREF" values for routes from its 
customers than from other service providers. This practice 
provides some degree of protection for its customer routes, 
and it facilitates implementation of certain routing 
strategies. It, however, also complicates other routing 
implementations such as backup arrangement, thus, requiring 
customized "LOCAL PREF" configuration. 


Figure 1 shows a typical case of a backup arrangement in the multi- 
provider Internet. In Figure 1, AS1 and AS2 are both providers, and 
AS3 and AS4 are customers of AS1 and AS2, respectively. AS3 has 
entered a bilateral agreement with AS4 to provide backup to each 
other. That is, AS3 would use its direct link to AS4 to reach only 
AS4 in the normal circumstance, and for transit in the case of a 
failure between AS3 and AS1. To realize this routing agreement, AS3 
requests that its provider AS1 adjust its BGP "LOCAL PREF" 
configuration so that AS1 reaches AS4 via AS2. 


Chen & Bates Informational [Page 2] 


RFC 1998 


Figure 1: 
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Typical Backup Scenario 


most providers 
not on IP 
a 


technique known as as the BGP AS-path manipulation can be used. 


However, 


it is currently only available in certain vendor's products. 


There are several drawbacks with the the practice of AS-based BGP 
"LOCAL_PREF" configuration at the provider level: 


o The implementation tends to less efficient due to the process 


of coordination and configuration. 
process needs to be repeated each time a change 


a new AS) occurs. 


the 
adding 


More importantly, 
(e.g., 


o The AS-based customization complicates router configuration 


and increases complexity of network operation. 


It has become 


a serious scalability issue for providers. 


o It can not implement prefix-based configuration without the 


AS-path manipulation 


(i.e. 


, usin 


g fake AS). 


o Keeping configuration up-to-date is some times problematic. 


3. How the BGP Community Attribute Can Help 


3.1 Overview of the Community Attribute 


The BGP community path attribute is an optional transitive attribute 


of variable length [1,2]. 
octet values, 


each of which specify a community. 


The attribute consists of a set of four 


The community 


attribute values are encoded using an AS number in the first two 


octets, 
in [2], 
share some common attribute. 
communities. 


communities listed in the attribute. 
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with the remaining two octets defined by the AS. As defined 
a community is a group of destinations 
Each destination can belong to multiple 
All prefixes with the community attribute belong to the 


(i.e. prefixes) that 
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The BGP community allows one to group a set of prefixes and perform 
routing decisions based on the identity of the group. 


The well-known communities NO_EXPORT (OxFFFFFF0O1) and NO_ADVERTISE 
(OXFFFFFFO2) are intuitive, and can be used for optimizing routing 
and for improving route aggregation. 


3.2 Community-based Configuration 


With the BGP community attribute [2], a provider can now use 
community-based, rather than AS-based, configuration of BGP 

"LOCAL PREF". The provider first needs to coordinate with its 
customers a set of communities to be mapped to certain BGP 

"LOCAL _PREF" values. The provider can then apply a uniform BGP 
configuration to all its customers that would capture routes with the 
community values, and set up the appropriate BGP "LOCAL_PREF" values 
accordingly. A customer that requires customization in its provider 
BGP "LOCAL PREF" configuration can simply send the appropriate 
community values in its routing announcements. 


The major advantages of using this technique include: 


o The customer has full control in the process, which makes a 
lot of sense as the customer is in a position to have better 
understanding about its own topology and routing policy 
requirement. 


o The effect of route-based customization in BGP "LOCAL PREF" 
configuration by providers can now be achieved, thus, removing 
the need of AS-Path manipulation in certain cases. 


o It addresses the scalability issue facing providers as it 


distributes the configuration work to the customer that 
requires customization. 
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4. A Real-World Implementation Example 


MCI currently makes heavy use of the BGP "LOCAL_PREF" attribute value 
as part of its routing policy configuration process. Different BGP 
"LOCAL_PREF" values are assigned for routes from different sources. 
Table 1 details these values: 


4------------------------- +------------ + 
| Category | LOCAL_PREF | 
oS Seneca Ss Sosa eee St eens fesisoesas-is + 
|Customer Routes | 100 | 
|Customer backup Routes | 90 | 
[Other ISP Routes | 80 | 
|Customer-Provided backup | 70 | 
e e oS peo SS sc See $oSeSossoose= + 


Table 1: Defined LOCAL PREF Values 


Note: 


o The value ’100’ is the default value used within our network 
configuration. 


o In most cases, the MED attribute set by a customer is 
sufficient for customer backup routes (e.g., Tl backs up T3). 
However, in certain cases configuration of "LOCAL _PREF" will 
still be necessary until the BGP DPA attribute is available. 


To make use of the BGP community attribute, several community values 
(MCI’s AS number: 3561 = O0x0DE9) have been defined that can be used 
by customers to tag routes so that the appropriate "LOCAL PREF" 
values are configured. Table 2 lists the appropriate community 
attribute values (and the mappings of community to LOCAL_PREF): 


FoSSscSse A E E + 
| community | LOCAL_PREF | 
peheee chedntn bata cae hrs | Salsa oe maasmerhen + 
|3561:70 (Ox0DE90046) | 70 | 
|3561:80 (0x0DE90050) | 80 | 
|3561:90 (Ox0DE9005A) | 90 | 
4+--------------------- +------------ + 


Table 2: Community to LOCAL_PREF Mapping 
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A customer requiring MCI to configure BGP "LOCAL _ PREF" values other 
than the default can tag their routes with the defined communities. 
The community values can be configured either based on an AS path 
list or an IP address access list. A cisco systems software specific 
configuration example is given in Appendix A to show how this can be 
achieved. 


A uniform BGP configuration (see Appendix B, again cisco systems 
software specific) is applied by MCI to peers with customers that 
configure the appropriate "LOCAL PREF" values based on the 
communities received. 


This technique has been tested and is in use with several customers, 
and the response has been very positive. We are in the process of 
migrating all other customized BGP "LOCAL_PREF" configurations to 
this uniform community based configuration approach. 
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Appendix 


These appendices list cisco systems software specific configuration 
examples for configuring communities, and for uniform route-map 
definition that sets up the appropriate "LOCAL_PREF" values based on 
the corresponding community values. These examples are given purely 
to show a working example of how the desired effect discussed in this 
document can be achieved. Please refer to [6] for more specific 
information on cisco configuration and syntax. 


Appendix A. Community Configuration 


The community values can be configured either based upon an AS path 
list or based an IP address access list. Here is an example that 
includes both cases: 


router bgp xxxx 


neighbor x.x.x.x remote-as 3561 

neighbor x.x.x.x filter-list 20 out 

neighbor x.x.x.x route-map config-community out 
neighbor x.x.x.x send-community 


!!# match all 

ip as-path access-list 1 permit .* 

! 

!!# list of customer ASs 

ip as-path access-list 20 permit ^$ 

ip as-path access-list 20 permit %64700_ 
ip as-path access-list 20 deny .* 

1 


!!# AS path based matching, backup for another ISPs customer 
ip as-path access-list 40 permit _64710_ 

ip as-path access-list 40 permit _64711_ 

ip as-path access-list 40 deny .* 

! 


'!# route-map 

route-map config-community permit 10 
match as-path 40 

set community 0x0DE90046 

route-map config-community permit 20 


match as-path 1 
l 
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Note: The community can also be configured based on IP prefixes 
instead of AS numbers. For example, 


access-list 101 permit ip 192.160.154.0 0.0.0.0 255.255.255.0 0.0.0.0 
! 

route-map config-community permit 10 

match ip address 101 

set community 0x0DE90046 

route-map config-community permit 20 


match as-path 1 
l 


Appendix B. Uniform Route-map Configuration 


Here is the uniform route-map that can be used for all BGP 
customers: 


!!# routes primary via another ISP 

ip community-list 70 permit 0x0DE90046 
ip community-list 70 deny 

l 


!!# routes also homed to another ISP, but with DPA or 
!!# AS-path length as the tie-breaker 

ip community-list 80 permit 0x0DE90050 

ip community-list 80 deny 

1 


!!# customer backup routes 

ip community-list 90 permit 0x0DE9005A 
ip community-list 90 deny 

1 


!!# the route-map applied to BGP customers 
route-map set-customer-local-pref permit 10 
match community 70 

set local-preference 70 

route-map set-customer-local-pref permit 20 
match community 80 

set local-preference 80 

route-map set-customer-local-pref permit 30 
match community 90 

set local-preference 90 

route-map set-customer-local-pref permit 40 
match as-path 1 


set local-preference 100 
1 


Chen & Bates Informational [Page 9] 


